|
|
|
|
|
|
|
Figure 2.8.
The initial class model. |
|
|
|
|
|
|
|
|
The notations 1..1 and 1..* together are known as the relationship's cardinality. That is, because there is only one BankAccounts object, its cardinality is 1..1; because you can have one to an unlimited number of Account objects in your collection, Account's cardinality in the relationship is 1..*. The asterisk (*) represents an unlimited number. The Customer and CheckingHistory classes are relationships that have meaning only with respect to the actors in your system. These actors' events can be formalized in your system through control objects, a subject you will examine on Day 3. Day 3 covers the concept of the HasA, IsA, and Uses relationships in more detail. |
|
|
|
|
|
|
|
|
Today you learned that the three primary roles usually involved in the use case identification process are the requirements gatherer, the object-oriented analyst, and the architect. You saw that the requirements gatherer typically interrogates end users, business managers (or domain experts), and project managers to draft both a problem statement and optionally an initial requirements model. The object-oriented analyst then carefully examines the requirements model to understand the requirements and elaborate on the requirements model, to assess the implications of each requirement, and to remove inconsistencies and requirements that have been discovered to be no longer valid. Object-oriented architects work with analysts and designers to ensure that project team members can trace the names of business objects between the list of requirements, analysis models, and design models. Architects sometimes perform the roles of both the analyst and designer; otherwise, the architect is a mediator and final decision-maker of the |
|
|
|
|
|
